FastSemaphore

FastSemaphores differ from classic semaphores in the following ways:

• There is no initial count.
• There is no max count.
• There is an auto release count that is passed to RtInitializeFastSemaphore. This count represents the number of concurrent waiters that causes a simultaneous release. For example, if auto release count is set to 4 and 4 threads call RtAcquireFastSemaphore, all threads will release the wait once the fourth one is called.
• A thread that calls RtAcquireFastSemaphore uses a busy-wait. As a result, it should not be used on the first RTSS processor, as it will interfere with RTX64 Subsystem.
• Because it does not use the RTSS object layer, there is no way to create a named fast semaphore. This also means that it will not appear in Rtx64Objects output or RTX64 WinDBG extension information.
• There is a RtReleaseAllFastSemaphore API that can be used to release all waiters at once.

Since there are no objects associated with FastSemaphores, there are a number of restrictions that developers should be aware of before using a FastSemaphore:

• All threads sharing a FastSemaphore must be in the same process.
• All threads should have access to the same semaphore variable. In other words, it cannot be defined in a thread scope. The semaphore variable must be allocated for the duration of all busy-waits.
• The controlling process must not be terminated while a wait is active.
• All waiting threads must exit before the process exits or the process may hang.
• The developer must carefully manage thread priorities. Threads are not protected by priority inversion protocols.
• FastSemaphore relies on a busy wait, so you should disable watchdog monitoring since a FastSemaphore can trigger an unintentional Starvation exception.
• Threads sharing a FastSemaphore should execute on different processors to ensure that:
• A busy-wait thread does not interfere with the FastSemaphore release thread.
• A high priority busy-wait thread does not interfere with a lower priority FastSemaphore release thread.

NOTE: Internal objects are created from the system's internal allocation space (IntMSpace) when local memory is used.

Topics:

• FastSemaphore Functions